Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d8/ozbii11d.arc/OZBEXT.DOC

Text File | 1990-08-06 | 36KB | 652 lines

                                   OZBEXT II
                                  Version 1.1b
    An external protocol module for the CompuServe "B" and "BPlus" protocols

                             Copyright(c)1987,1990
                                  Steve Sneed
                              CIS ID# 70007,3574


Welcome to OZBEXT!
------------------

OZBEXT II is an "external protocol module", a program that allows you to add
the CompuServe "B" and "BPlus" file transfer protocols into other communi-
cations programs.  While not designed primarily as such, the program can
also be used as a (limited) stand-alone communications package for accessing
the CompuServe Information Service (CIS).

Popular file transfer protocols such as XMODEM do not function well under
CompuServe's complex packet-switching network.  The KERMIT protocol, while
operational, is very slow on CIS.  CompuServe developed the B/B+ protocols
to provide optimum performance on the network - it is the recomended method
of file transfer when using CIS.

OZBEXT II works with all major commercial and shareware/freeware communications
programs, and can be used with any comm program that can shell out to DOS
without dropping the connection.  On those programs that provide the capa-
bility, OZBEXT II works best when set up as an external protocol callable from
within the program (examples are ProComm Plus, QModem, Boyan and GT-PowerComm.)
A wide range of options, both on the command line and within the program, allow
you to configure the program to match your needs.  The program automatically
matches itself to your existing communications port configuration, meaning you
do not have to worry about setting things like baud rate and parity when
calling the program.

If you want or need the ability to view CompuServe's RLE and GIF graphics,
such as the radar weather maps, CB pictures, stock trends analysis, and the
over 6000 graphics images in the Graphics Forums, you will want to get OZBEXT
II's sister program, OZRLE.  OZRLE provides all the capabilities of this
program plus adds the ability to view, offline or online in realtime, the
available graphics files and displays CIS provides.  In addition, OZRLE
automatically captures images viewed online to a file for later offline
viewing, saving you substantial connect-time charges.  OZRLE supports all major
IBM video hardware types, including Hercules monochrome, CGA, EGA, MCGA, VGA,
and many "Super" VGA cards.  If you need online graphics capability on BBS's
and other services then BBSGIF will fit the bill; it provides all of the online
graphics capabilities of OZRLE but uses the XMODEM-type protocols.


Before we start...
------------------

Please read this documentation completely.  I know you want to get using the
program right away, but taking a few minutes now may well save you time and
money (in connect-time charges) later.  The program is very simple to use,
and for most users' configurations is fully automatic, but an ounce of pre-
vention is worth a pound of cure.  Thanks!

Users of previous versions please note: while much appears the same in this
version, it is completely new; at a minimum please review the command line
switch/environment variables section and the "For users of previous versions"
sections before striking out with this new version.

It is assumed throughout this document that you have a good basic under-
standing of DOS commands, batch files and batch file commands, what
"environment variables" are and how to set them.  If this is not the case,
please have a good MS-DOS tutorial book handy in case I use unfamiliar
terminology.

Help for this program is available online in the IBMNew forum on CompuServe.
Many program-specific help files written by SysOp Connie Kageyama are
available in LIBrary 2 of that forum.  Do a "DIR *.HLP" at the "!" prompt
in that library for a list of those files, or do a "BRO/KEY:HELP" at the
same prompt.  The sysops themselves are available to answer questions, and
of course I check the forums daily to help users.



The Legalities...
-----------------

This program is the copyrighted work of its author, Steve Sneed.  All rights
under US copyright law are reserved.  The author hereby grants to private,
noncommercial users of this program a limited license to use, copy and
distribute the program free of charge, as long as:

a) the program and its accompanying files are not modified in any way other
   than changing the "archive format" used to store and transmit the program;

b) no charge is made for any distribution beyond a nominal disk/duplication
   fee; and

c) the distribution of the program is not done by a business, company or
   private entity whose primary business purpose is the distribution of
   public domain and/or "shareware" software, by any means magnetic or
   electronic, for profit.  Specific exclusion of this clause is hereby
   granted by the author to The First Osborne Group (FOG) and The Public
   (Software) Library.  This clause does not limit distribution by Bulletin
   Board Systems or other information services, and a fee may be charged
   for such access as long as such fees are not charged specifically for
   this software.

If the program is used for commercial purposes, a license from the author
is required along with payment of a $15 license fee per copy.  Multi-copy
and site licenses are available; contact the author at the address listed
at the end of this document for more information.  "Commercial purposes"
as used above is defined as use by a company or government service or
organization in an official capacity, or use by a company or individual
whereby financial profit is made from such use - for example, a stock broker
who uses the program to aquire ticker information for clients.  Specific
exclusion of this clause is hereby granted by the author to CompuServe Inc.,
Borland International, TurboPower Software, and PCMagNet.  No other rights
are in any way relinqushed by the author, and the author reserves sole right
to grant and administer licensing and distribution.

This software is provided "as-is", without warranty of any kind, including but
not limited to any warranty of mercantibility or suitability for a specific
purpose.  At no time will the author be held liable for any loss or damage,
including loss of data or time, due to any operation or use of this program,
even if the author has been informed of such loss or potential for loss.

"GIF", "GIF Format" and "Graphic Interchange Format" are Service Marks of
CompuServe Inc., an H&R Block Company.


Installing OZBEXT II
--------------------

OZBEXT II generally should be installed in the same location as your comm
program. If you use a hard disk, this means in the same subdirectory.  If you
use more than one comm program with OZBEXT II and have different programs in
different subdirectories, be sure to place OZBEXT II in a subdirectory that is
on your DOS path.

OZBEXT II is delivered to the CompuServe forums in "ZIPped" format, using the
PKZIP 1.10 utility by Phil Katz.  Some forums (and BBS systems, if that is
where you aquired this program) may re-compile the program files into a
different archive format such as the .ARC format, or may use a utility like
LHARC to create a self-extracting program archive.  Once you have copied the
archive file or self-extractor onto your disk, you will need to use the
appropriate un-arc utility (if not a self-extractor) to un-arc the program
files back to their original runable state. Utilities for this purpose are
available in most forums on CompuServe, and on nearly every BBS in the world.


Configuring OZBEXT II
---------------------

Configuration of OZBEXT II is very simple.  The program uses a "standard"
internal configuration that will be correct for 90% or better of users.
The program is quite flexible, however; almost any type of special con-
figuration used on CIS is supported by the program, as well as several
options governing the way the program functions or performs.

The following list contains OZBEXT II's nominal configuration.  Only if
your particular configuration differs from this list should you worry
about the various settings available.

* Uses the COM1: serial port/modem.
* Uses the chosen port's existing baud rate, parity and data/stopbits settings.
* Uses full-duplex communications.
* Provides an audible alarm at the end of a protocol transfer.
* Returns to its own internal terminal mode at the end of a transfer.
* Uses the DOS current working directory for storage of downloaded files,
  and looks in the same directory for files to upload.
* On exit, leaves the modem CarrierDetect line high and restores the port to
  the same configuration in which it was found.
* Perform no logging of transfer success.


Setting Options
---------------

If one or more of the above settings does not match your configuration, there
are two possible ways to change things.  The first way is thru setting
variables in the DOS environment.  The second is to use command line parameters
when executing the program.  If you are calling OZBEXT II from a program such
as QModem that wants to see a batch file rather than a free- standing program
to execute, it is simpler to use the command line parameters within the batch
file (saving the DOS environment space for other programs.) Parameters set via
environment variables can be overridden via command line options.

Below is a list of OZBEXT II's environment variable names and the associated
options:
DSZPORT=?
  or
OZPORT=?         Replace ? with your commport number (1 - 4 for PC-compats,
                                                      1 - 8 for MCA machines)
OZPATH=?         Replace ? with the full path to use for up/downloaded files

When using command line parameters, all parameters must begin with either
a dash (-) or a forward slash (/) character.  Parameters that require qual-
ifying information (such as the port selection parameter) must have the
information immediately after the option letter with no space.  At least
one space must separate each parameter.  Below is the list of available
parameter option letters:

C{portnumber}   Select the comport.  If you use COM2, this would be "/C2".
                The default is COM1.  Ports 1 thru 4 are available for PC-
                compatible machines, and ports 1 thru 8 are available on
                PS/2's and other MCA-buss machines.



If you are using the program as a stand-alone comm program rather than from
within another comm program (and, generally, _only_ when you use it as such),
4 other parameters are available to configure the port.  They are:

B{baudrate}     Specifies the baud rate setting at which to open the port.
                Available baud rates are 300, 1200, 2400, 4800, 9600, 19200,
                38400 and 56000.  The default is to use whatever setting the
                port currently holds.

P{parity}       Specifies the parity setting to use.  Normally either None
                or Even, but Odd, Mark and Space settings are available as
                well.  You only have to provide the first letter of the
                parity type word (so setting None parity would be "/PN".)

W{dataword}     Specifies the data word length; 5, 6, 7 or 8 databits.

S{stopbits}     Specifies the number of stop bits (almost always 1.)


The other available parameters are used to configure the way OZBEXT II works.
They are:

X               Exit OZBEXT II immediately on completion of a protocol
                transfer. The default is to return to OZBEXT II's internal
                terminal mode so you can download more files or navigate to
                another area of CIS.  This option is normally only used when
                the program is being called from within another comm program's
                script file for automatic execution.

J               Log results of all transfers to OZBEXT.LOG.  The file is
                created if it does not exist.  The default is to not log
                xfers; this just allows those that want logging to have it.

D               Drop carrier on exit.  The default is to leave CarrierDetect
                high.  Using this parameter will mean that OZBEXT II will break
                any existing connection on the modem when exiting - not a good
                idea when you are loading the program from within another
                comm package.

N               Turn off the audible alarm normally provided at the end of a
                protocol transfer.  The default is to provide a beeper at
                the end of a proto transfer and wait for a keypress before
                continuing.  When this switch is used, no alarm sounds and
                the program does not wait for the keypress.  (Version 13.1cd
                note: this turns off *all* noise, including the system bell
                when a ^G is received.)

Q               Automatically send an XON character on startup.  This param
                is normally only used with the CIS-specific "auto-navigator"
                programs AUTOSIG and TAPCIS, both of which send an XOFF flow
                control command to CIS when shelling out to DOS.

U               Automatically send a Ctrl-U character on startup.  Using this
                parameter means that, on startup of OZBEXT II, the CIS system
                will automatically interrogate OZBEXT for its terminal-type
                and protocol-support capabilities.  This option should be
                used with caution; in a few places that you might call OZBEXT
                II the sending of the Ctrl-U may confuse the CIS system or may
                abort the imput prompt that was waiting when you called OZBEXT
                II.


L               Use a large (block) cursor while in the program.  This can be
                handy for those using the program on a laptop.  Laptop users
                will probably want to use the OZCOLS program to set the display
                colors to a reasonable set for their display type as well.

O               Turns off checking for the Carrier Detect signal from the
                modem during use.  Normally OZBEXT II checks for this signal
                during a protocol transfer and if the signal is lost (for
                example, when the phone line connection is broken due to
                line noise or other problem) the protocol transfer is
                automatically aborted.  Some CIS users are lucky enoough
                to be connected to the network via direct serial link; these
                links are usually a minimal 3-wire connection without CD
                support.  Users so configured should use this switch; do
                not use this switch if you connect to CIS via modem unless
                you experience problem initiating a transfer.

F{path}         Tells OZBEXT II to put all downloaded files in the {path}
                drive and/or subdirectory, and to take all uploaded files
                from that same location.  OZBEXT II verifies that the specified
                path does exist and if it does not notifies you of the error
                and reverts to the current DOS working directory.  Note that
                you can override this path by including any desired path with
                the filename when answering the "Filename for your computer:"
                prompt from CIS right before beginning the transfer.


Running OZBEXT II
-----------------

OZBEXT II is simple to use.  Depending on what general communications software
you use, it can be made almost automatic.  Due to the wide range of different
communications programs available, no one setup will always be right for
your particular configuration.  However, following these guidelines will make
using the program simple and straightforward.

1)  If your comm program supports it, always install OZBEXT II as an external
    protocol module.  Some programs or versions of programs do not support
    defined external protocol modules but do allow the definition of external
    programs (like editors.)  If this is true for your software, use that
    type of setup.  Only use OZBEXT II from a "general" DOS shell if your soft-
    ware provides no other support for external programs.  Installing OZBEXT II
    as an external protocol module means calling OZBEXT II will be done in the
    same manner as all other protocols, giving you a consistant interface.

2)  If your program requires batch files for external protocol modules (ala
    QModem and a few others), do all parameters options on the batch file
    command line.  Here is an example batch file for QModem:

    ECHO OFF
    CLS
    OZBEXT /c2 /fA:\DNLD\TODAY
    CLS

    This type of setup is also recommended if you use the program from a
    "plain" DOS shell or from within AutoSIG or TAPCIS, or if you run the
    program standalone.

3)  If your communications program is like Boyan (where you can call the
    program directly), it is better to use environment variables to set
    any needed options.  This is best done in your AUTOEXEC.BAT file so
    that the variables are always set.  Programs like Boyan make it easy
    to set a single configuration but make it difficult to modify that
    configuration for special cases; make your setup flexible.

4)  In all the above cases, note that unlike most other protocol modules
    OZBEXT II does not distingush between upload and download on the command
    line.  This is handled at the start of a protocol transfer by the protocol
    itself.  Therefore, you generally only need one configuration for both
    the upload and download entries in your comm program.  However, a tip here
    is that if you use different subdirectories for storing downloads and
    finding uploads, you can set up separate configurations with different
    paths on the /F option on the command line (either batch file or direct
    command methods), or set an environment variable for the files path for
    downloads and override it with a command line setting in the upload setup.



Using OZBEXT II
---------------

Most protocol modules, when executed, immediately enter the protocol itself.
The B protocols do not work this way.  CIS sends a special interrogation
sequence to the remote system (you) to make sure the remote can in fact do
B and/or B+ before initiating the protocol itself.  OZBEXT II _must_ be loaded
and running to reply to this interrogation properly, or you may well not be
able to do the transfer.  (This is not a deficiency, it is a safety mechanism
for both CIS and you.)  Many places on CIS where you can transfer files, this
interrogation may not be done immediately prior to the protocol initiation;
often it is done when you first request a transfer but before CIS has asked
you for the filename to process and the file type (binary or ASCII.)  Because
of this you should call OZBEXT II _before_ you request the transfer.  OZBEXT II
comes up in terminal mode so that you can answer any pending prompts, etc.

Usually, when you shell out to OZBEXT II from another comm program, there is
a prompt from CIS pending input.  There is no way OZBEXT II can know what this
prompt was and therefore redisplay it (or anything else that was on the screen
when you called it) so you must remember what the prompt was and reply to
it after OZBEXT II is operational.  This is no problem; just type in what you
would have had you been sitting at the prompt.  CIS never sees OZBEXT II load
so it never knows you were not able to see the prompt.

Some users have noted that they "forget I'm in OZBEXT II rather than my main
program."  OZBEXT II provides a status line at the bottom of the screen at all
times to remind you.  I have tried to make sure it does not resemble too
closely the status lines provided by many other comm programs, to make this
recognition easier.   An added tip here is to use the OZCOLS utility program to
set the colors used by OZBEXT II do some set different from your main program.

Many CIS users (most?) log in at 7 bits/Even parity.  OZBEXT II has no problem
with this; it knows how to switch to 8 bits/No parity for the actual transfer
and back at the correct times.  HOWEVER... some serial ports and/or modems
do not handle the "flying switch" properly and will cause grief.  For this
reason I recommend you use 8 bits/No parity at all times on CIS.  To do so
you must change some of your "user profile" parameters that CIS maintains
on you.  At any CIS "!" prompt, issue a GO TERMINAL command and follow the
menus.


Commands Within OZBEXT II
-------------------------

OZBEXT II provides several commands while operational.  These all are used to
modify the same functions you set with command line options or environment
variables.  Generally, the letter used for a particular option setting in the
list above will be the key used with the [Alt] key to modify that option while
in OZBEXT II. To see a menu of available Alt-Key commands in the program, press
the [Home] key.  One extra command is available, however: Alt-X is used to exit
the program.



CIS Protocols
-------------

There are three distinct species of B protocol supported by CIS: "Classic" B,
"Quick" B and B Plus.  Most CIS users know that Classic B is the old (and slow)
version of the protocol, but there seems to be a large amount of misconception
concerning QuickB versus BPlus; many users assume that QuickB is faster than
BPlus and therefore preferred (I guess because of the "Quick" in the name.)
This is incorrect.  QuickB and BPlus use almost exactly the same core
procedures to perform the transfer, and under nominal conditions the two will
post identical or nearly identical transfer times.  What BPlus adds is
flexability and safety, by adding features such as Aborted Transfer Resume and
better file management including file information transfer at protocol start,
and more flexible protocol packet size.  BPlus is always the preferred version
to use.

Note that in many areas of CIS where a menu is displayed for protocol type,
only the "B" and "QuickB" types are listed.  Both QuickB and BPlus are designed
to negotiate the actual protocol type level during the protocol startup
handshaking, but some early QuickB implementations (not this program) did not
properly handshake the type - CIS accomodated these ill-behaved programs by
making the QuickB option available in transfer menus.  However, when using this
program, you should always respond with "B" at such a menu so that OZBEXT can
properly handshake the negotiation with the host; selecting "QuickB" at such a
menu forces QuickB mode from CIS and will cause problems when attempting to
resume an aborted transfer as well as locking OZBEXT II into the 512-byte
packet size (rather than the optimal 1024-byte size at 2400bps.)


Protocol Performance
--------------------

Another common misconception is that packet size has a large effect on protocol
performance.  It does indeed effect performance, but not in the way most folks
assume.  The difference in performance at 2400bps between 512-byte packets and
1024-byte packets is seldom more that 3% (unless network loading is heavy) *if*
no transmission errors occur.  In the face of protocol errors where packets
must be resent, smaller is often better because less time is wasted resending
data.  The total size of the transfer, number of errors, network type and
network loading factors cloud the issue, to the point that meaningful
comparisons are quite difficult to achieve.  OZBEXT II juggles default packet
size based on the current baud rate - 128 bytes for 300 baud, 512 bytes for
1200bps and 1024 bytes for 2400bps.  This strikes a reasonable balance between
optimal thruput with no errors, and resend time in case of errors; each packet
will take 4 to 5 seconds to send/receive at the current baud rate.  Some BPlus
implementations lock the packet size at some value, usually 512 bytes.
Sometimes this is for simplicity's sake, and sometimes because there are
factors besides file transfer thruput to be considered (CompuServe's
Information Manager is an example of the latter.)  OZBEXT II has been designed
with one thought in mind: do everything it can to get the highest possible
thruput during the file transfer.  It has proven to be consistently as fast or
faster than any other program available that supports the QuickB and BPlus
protocols, including CIS' own programs.



Users that are used to the transfer rates seen when connected to BBS systems
are oftem shocked and disappointed at the transfer rates seen on CIS.  Keep in
mind that, when connecting to a PC-based BBS, you are connecting to a system
where the entire resources of the computer can typically be devoted to
processing the protocol; such systems can on a clean connection turn optimal
transfer rates for the baud rate used.  CIS is not a BBS; it is a group of
several large computers sharing processor and system resources amomg dozens
or even hundreds of users at any given time.  In order to allow access by all
these people all over the world, CIS uses a special network of phone lines and
satelite links called a "packet-switched" network.  The packet switcher is what
makes all of this possible, but it also introduces delays in communications, so
the typical transfer rate to/from CIS is often lower than a comparable transfer
to/from a dedicated BBS.  The B series protocols have been designed with these
delays in mind, so a QuickB or BPlus transfer should show a very close to
optimal rate under light to moderate network loads.  When network loads are
heavy (such as early weekday evenings, especially Mondays), performance can
still drag down.  Also, connecting thru a supplimental carrier such as Tymnet
can effect performance, as can connecting thru a busy node with several other
users.  If you are concerned with the time you spend online to CIS and have
large and/or many files to transfer, it behooves you to plan your session ahead
of time, including running the session during off-peak times like the small
hours of the morning or weekends.  Taking advantage of OZBEXT II's resumable
transfers, by aborting the download and trying again at a different time or
thru a different node when you see that network delays are seriously slowing
the transfer, can also save you time and money.



The Protocol Window
-------------------

During a protocol transfer a window appears on screen detailing the transfer
activity.  Most things about the window are pretty self-explanitory, but one
area deserves clarification - the "Port" and "Data" percentages on the "Ef/Tm"
(Efficiency/Time) line.  The percentage displayed in the "Port" column is the
comparison of current protocol "raw" port rate to the current port baud rate
setting of the UART.  In other words, at 2400baud this figure would optimally
be 100% if we were seeing 240 bytes per second comming in the port during a
transfer.  Since CIS uses its packet-switching network and network delays of
some magnitude are inevitable, this figure will almost always be less than
100%.  Normally you can expect greater than 230 cps "raw" rates on downloads,
with uploads usually a bit more.  Connections established thru suplimental
carriers such as Tymnet may well be less.  The percentage under the "Data"
column, on the other hand, is the ratio of total data bytes received to the
protocol's average "raw" port rate.  In other words, the efficiency of the
actual data comming in the port.  This figure normally runs around 92 - 96%
for binary files and 98 - 99% for ASCII text files.  However, bad packet
resends when an error occurs and is corrected cause this figure to drop,
sometimes dramatically.  Providing both figures makes it easier for you to
decide when to abort a transfer.  If the "Port" figure is dramatically low
(usually due to a high network traffic load but can also be due to delays
caused by suplimental carrier networks), you may want to abort the transfer
and wait until network traffic had dropped so good port rates are possible.
If the "Data" figure is low (usually due to a high error-packet count), you
may want to abort and call back on another node.  To avoid confusion, just
remember that the "Port" efficiency percentage gives data on how efficient
the port is operating, while the "Data" percentage gives overall port-to-data
efficiency regardless of actual port rate or port efficiency.  The time display
under the "File" column is the time the transfer has taken so far, while the
time under the "Remaining" column is an estimate of the time it will take the
rest of the transfer to complete.  The "Remaining" time figure will vary based
on the current port rate, because it is recalculated at the end of each packet.
Oh, one other thing: users with high-speed modems that run the port-to-modem
link at 19.2Kbps or higher will see some really poor port eff. values.
Remember that OZBEXT II uses the actual UART chip's baud rate setting to
perform its calculations and cannot know to what speed the modem is throttled,
so on a 19.2Kbps modem and 2400bps line you will see port rate of less than
20%.  The Data eff. rate will always be correct, since it is dependant on
actual port thruput rather than hardware settings.



For users of previous versions...
---------------------------------

You may have noticed that this version is called "OZBEXT II".  This program
is now going on 3 years old, and has seen about 12 versions released to the
public.  It has matured from a somewhat flakey but servicable B-protocol only
module in its original release to a solid program covering the full range of
current-generation CompuServe-developed protocols, and from a single small
file-transfer-only program to a whole family of programs supporting online
graphics and other special features of CIS.  It has seen a steady stream of bug
fixes and enhancements, and about once a year, it has received a complete,
top-down rewrite.

This new one is that annual rewrite.  While it looks and acts very similar
to every version since 10.1, it is in no way the same "under the hood."  The
entire program is written using Object-Oriented Programming techniques, from
the serial port library to the screen management to the protocol handler to
the terminal emulation manager.  There are a total of 75 lines of programming
source code kept from the last version, out of over 20,000 lines of code.
Also, previous versions relied very heavily on routines from TurboPower
Software's TurboProfessional and ObjectProfessional libraries' screen
management services, and in the latter library's case were somewhat topheavy
due to unneeded code being linked in; this version has a custom set of
windowing object routines based on just the OPro low-level capabilities and
optimized to its needs.

I set out to call this version "Version 20" (all development and early testing
were done under that name), but realized that such a complete overhaul deserved
a new name.  With literally thousands of users, a whole new name was out of the
question (not to mention the possiblitiy of death threats from forum sysops!),
yet it needed something to distingish it from earlier versions... so OZBEXT II
was born.

Specifics: support for MCA commports above COM 2 is now fully automatic, so the
/A and /I commandline and environment parameters are gone (if you are using a
multiport card with ports at non-standard addresses or otherwise have oddball
hardware, I will be happy to see what can be done in a custom version.)  The
bug that caused problems with Abort Resume for those using the DOS utility
SHARE with large partitions or on networks, and for DesqView users, has been
removed.  DesqView awareness in the screen management has been improved.
CarrierDetect checking throughout the program (especially at protocol startup)
is dramatically improved, to eliminate the problems some users experienced with
error messages from CIS and aborted transfer starts.  Port handshaking is
faster and smoother, so users with high-speed modems that want to run the port
at 19.2Kbps or 38.4Kbps can do so safely and reliably.  A couple of bugs in the
detection and handling of 16550A-series UART chips have been squashed, and
16550A-series UARTs are now fully supported at the maximum 14-byte buffering
level.  Users calling from overseas should find the program more robust in the
face of intermittant PADs and phone systems.  Overall, the program is faster,
smoother and more robust - and it is smaller than the last few versions.

One important note: the OZPAT utility program that could be used with previous
versions to set the program's colors will not work with this new one.  A new
program that replaces that utility, called OZCOLS, is available.



Kudos, Credits, Karma Enhancements
----------------------------------

The sysops of the IBMNet forums on CIS: Don Watkins, Connie Kageyama, Chris
Dunford and Vern Buerg.  My primary beta testers, and the greatest group
of folks around.  Ditto for Valerie Zen and Tom Potoki, sysops of the Graphics
Forums on CIS, who also help test.

Kim, Brian, Rich and Terry (especially Terry) of TurboPower Software, for
writing and maintaining the best libraries of Turbo Pascal utility routines in
the free world.

Russ Ranshaw ("Wiz10") and others at CIS, for providing exellent documentation
on the B+ protocols, and understandable source code for same.  Ditto to Brion
Jones of CIS for informative literature on interrogation/response sequences
and terminal reply codes.

Most importantly... you, the users.  Your questions, criticisms and sugges-
tions have helped make the program what it is.  If you like it thank yourself,
not me.


Point of Contact
----------------

I can most easily be reached via CompuServe at ID# 70007,3574.  Please leave
questions in either IBMNEW or IBMCOM rather than EasyPlex; other users or the
sysops may well be able to give you a faster answer.  If you need to contact
me concerning registration, please do so by EasyPlex or US mail:

Steve Sneed
409 San Juanico
Santa Maria, CA.  93455

This program is not shareware in the traditional sense; I do not require
private non-commercial users to register or pay a license fee (see the section
on license requirements at the top of this document.)  If you have a burning
urge to send me money anyway... I won't turn it down. <grin>  Please make
checks payable to Steve Sneed.  Updates are only done thru CIS; I do not
notify users of updates (except for fully-licensed commercial users.)  If
you are registering for full license, please plainly state so in your
corospondence along with how you are using the program.  Site licenses and
multi-license discounts are available; please contact me for specific info.
Finally, please do not call me voice, and I cannot accept any collect calls.
Thanks.

I hope you enjoy the program!

<eof>